Optical Transport Network (OTN) generally relates to protocols providing an efficient and globally-acceptable way to multiplex services onto optical light paths. Advantageously, OTN is fully-transparent for underlying multiplexed signals and offers rich management features. For example, OTN is defined in part by International Telecommunication Union Telecommunication (ITU-T) Recommendation G.709/Y.1331 “Interfaces for the Optical Transport Network (OTN)” (December 2009), the contents of which are herein incorporated by reference. Generally, client signals are mapped into Optical channel Payload Units (OPU) which may be mapped into an Optical channel Data Unit (ODU) at k layers with bit rates defined for each k layer (k currently defined for 0, 1, 2, 2e, 3, 4 and flex). An ODUk may be mapped or multiplexed into an Optical channel Data Tributary Unit Group (ODTUG) of an associated or higher order layer which in turn may be mapped or multiplexed into an Optical channel Transport Unit (OTU) of an associated or higher order layer. In particular, Section 7 in G.709 details multiplexing and mapping of various data rates. Any number of levels and layers of ODUk mapping and multiplexing may theoretically occur given extensions of the standardized k layers. Currently defined k layers are 0, 1, 2, 2e, 3, 4 and flex, and future versions may be defined via 5, 6, etc.
The present state of ODUk and ODTUG mapping and multiplexing is either a fixed or manually provisioned structure. For example, a network element receiving ODU0 signals multiplexed in an ODU2 would have a fixed ODTUG02 which is then multiplexed with other ODTUG02 signals into an ODTUG23 and mapped into an OTU3. A network element receiving this signal would need to either support the same fixed ODTUG structure or support manual provisioning of arbitrary levels which could then be provisioned with identical ODTUG mapping. Provisioning end-to-end connections across network clouds then becomes an exercise in the micromanagement of the ODTUG structures at each intermediate link, depending on what mapping and multiplexing that particular network element supports. Available bandwidth within this structuring could exist at any associated or lower order ODUk level and must be manually located and provisioned as well. Another shortcoming with the conventional approach is that the network user needs to predetermine where and how their OTN traffic will be setup as well as how and where it is restored. If this is not done properly, it gives rise to bandwidth fragmentation and hence bandwidth is not used the best way it should be used. Further, interoperation between vendors is a problematic and many times not even possible due to the ODTUG structure.